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Conditional Conversational Command Processing 

ABSTRACT: 

A general programming tacility xs proposed tor 
communication with the interactive command languages ot 
time-sharing systems in an attempt to overcome some ot the 
current limitations ot data exchange between man and 
machine. Commands may be constructed in an arbitrary way in 
a string processing language and then processed as it typed 
to a console by a user. The output resulting trom the sent 
commands may be dissected and examined to determine 
subsequent action. 

fl set of functions to accomplish the above which could 
fc>e embedded into any string processing language is 
suggested, and necessary mlorma tion pertinent to 
implementation of the facility on existing time-sharing 
systems is given. 

Key Words: Time-sharing, Command languages, Pseudo-te Letype, 
Interaction, Conditional Job Control, Operating Systems 



CR Categories: J*. 30, 3. HI, 4.29, 1.3y 



Page J 



1.0 IN1FCDUCTION 



Experience with time-sharing systems has shown some 
unsatisfactory conditions concerning the communication 
between user and system. This communication talees place via 
a teletype or display console in the command language ot 
whatever program the user is operating. This paper will not 
concern itself with the design ot command languages but 
rather with the solution ot the tollowing problems: 

.A) Users of time-sharing systems find that there 
may be sequences of commands that they frequently 
enter with little or no variation. Even more 
annoying than the repetition may be the time 
required for the physical console to accept the 
command and print the reply, or, more seriously, 
the possible loss of information due to the 
inevitable occasional typing error. For example, 
it is common that at the beginning ot a session 
with the system, there is a standard sequence ot 
commands a user will give in order to retrieve his 
files from secondary storage, possibly assemble or 
compile them, and then initialize the particular 
subs y s t e ;u h e will u s e . 



Page 4 



B) A user may wish to enter a long series ot 
commands whxcli, due to interspersed computation, 
requires him. to be present at the console .tor a 
much longer period ot time than is necessary to 
type the .commands. For example, it a user wishes 
to assemble or compile several pacXages ot a large 
program, rather than issuing the sequence ot 
commands together, he may have to wait tor each 
computation to complete betore entering the next 
request, thereby partitioning his tree time. 
Time-sharing systems have proved invaluable tor 
speedy construction and debugging o.l programs but. 
there are many programs which, when completed, 
will compute tor a long period ot time with no 
need of human interaction. Some systems provide an 
offline mode lor running these programs but in 
general the command languages are ditterent Irorn 
the online command languages and less adequate. 

C) There are many dialogues with the computer 
which require very little creative intervention by 
the -user, His presence at the console may be 
necessary solely to chaperone the computation to 
check toe errors or to supply as input to one 
program the output of 'a previously executed one. 
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What, is needed in a time- sharing system is a continuum 
cf capabilities ranging trom pure non-interactive (read, 
batch processing) on the one hand to highly interactive on 
the other. 

2.0 HISTORY 



Some work which has been done in this area will now be 

described. 

In an early effort, since superseded, the SDS-yuu 
time-sharing system at Berkeley provided a system which 
wculd operate on a character tile in the following way: 
Characters would be taken trom the tile and delivered to a 
"pseudo-teletype". The system was deluded to believe that a 
pseudo-teletype was no different trom a real teletype, and 
that characters sent from the file were actually, typed at 
its keyboard. The pseu do- teletype would react to these 
characters in exactly the same way a real teletype would 
react it the same characters were typed to it by a user. 
The output response to this input at the pseudo-teletype was 
diverted to the console ot the programmer using the 
facility. A file might contain breakpoints which would 
cause interruption ot the program. Breakpoints could be 
placed wherever it was anticipated that creative or 
unpredictable intervention by a human was required. The 
user was allowed to interact arbitrarily with the 
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pseudo-teletype, through his own console, at these points 
and then type a command to continue sending characters trom 
the tile. 

CTSS, the time-sharing system tor the I3M 70y*J at MIT, 
made available to its users a program called a UNCO*. This 
is again a facility for sending a sequence or commands to a 
"pseudo-teletype". A macro facility (recursion and nesting 
■allowed) which permits assigning a name to a series ot 
commands is provided, as well as a restricted conditional 
facility. The conditional .facility is actually a special 
command in the time-sharing system which takes as an 
argument a symbolic name. If the name is not the name ot an 
existing file then the RUNCOfl program will asK the user 
whether or not to abort. Testing m this fashion proves to 
te cumbersome and very ad hoc but it is nevertheless found 
to be quite useful for detecting errors. 

While JCL, the job control language tor the IBM JfaU, is 
not a time-sharing command language it has attacKed 
analogous problems for batch processing. JCL. allows the 
definition of a sequence ot commands as a macro with 
symbolic. parameters. Calling a macro trom an input card 
deck after using special commands to initialize the values 
of its parameters results in the series ot parameterized 
commands being executed. JCL also has a conditional 
facility. Each "step" or statement of the command sequence 
has associated with it a "return code" which is a positive 
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integer assigned to the step after it has been executed. 
The return code is an error indicator returned by each 
executed coaaand upon termination. We can write a statement 
in the language which makes numeric tests on the return 
codes of -specified previously executed, steps. The result ot 
a test statement is to decide whether the next sequential * 
statement in the program is to be bypassed or executed. 

3.0 TBI LANGUAGE 



The above three systems are all similar in that they 
essentially provide a facility tor sending a linear 
sequential list of commands. to be executed as it entered 
from a console. The macros were introduced as a labor-saving 
device and the conditionals allowed a small amount ot 
control over the job being executed. We propose that a 
language with goto's, functions, conditionals, and 
generalised string pattern matching statements is more 
suited to the task of controlling interactive processes. 
The language should have the facility to send a command (or 
just a string of characters) to a pseudo- teletype and then 
wait for the complete response to this input. Subsequent 
action on the part ot the program can then be based on the 
content ot . the response (1. e. the output ot the 
pseudo-teletype) . With reasonable conversational features 
in the language, a program can selectively choose the 
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significant input and output required by the user and obtain 
the above mentioned continuum. 

We will provide below a list ot atomic functions which 
could be easily, embedded into an existing itnpleoientatxon ot 
any language with string-handling capabilities. These 
functions would provide complete, taimnum capabilities ♦tor 
communication with the pseudo- teletype « That is, a tunction 
will be provided which _ takes as argument a string ot 
characters. Galling the tunction will cause the characters 
to be sent to the pseudo-teletype. Other tunctions will be 
provided to collect the output characters. With this 
facility we can do arbitrary computation to, generate 
commands and then do complex analysis ot the response. We 
can itragine very grandiose applications ot the taciiity,- 
For example consider a program in a language containing the 
special tunctions which constructs programs in some other 
language. The constructed programs could be entered, 
compiled and executed on the pseudo- teletype and then 
evaluated on the basis ot their output. Another application 
would be to construct an interlace between user and system 
which is- radically ditterent rrom the standard command 
language provided. The string processing language could 
accept commands in the new syntax and then transform them 
into meaningful commands tor the standard command .language. 
Here cctrmonly, however, use ot the language would be to 
consolidate lengthy command sequences into a single 



Page V 

parameterized command. ?1echanical error checxing and other 
automatic operations would thereafter be removed from the 
user's responsibility. 

4.0 THE COMMUNICATION FUNCTIONS 

S complete set of atomic functions tor communicating 
with the pseudo- teletype will now be listed. The functions 
could be added to a processor ot any reasonable string 
manipulating language, like SNOBOL, TRAC, or COHIT, or even, 
in the form of system . calls, to assembly language. The 
syntax of the presented functions will naturally depend on 
the language of their embedding. 

LOGIN { <name> , <password> ) 

This function obtains a pseudo- teletype tor 
the program and enters the named user on it it the 
password is acceptable. Null arguments will cause 
the name and password ot the user running the 
■ program to be used. - The now active 
pseudo-teletype is left in a state where it is 
awaiting its first command. The function will tail 
and do nothing if the arguments do not result m 
a legal entrance to the system. 
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LOGOUT ( ) 

This function ot no arguments causes the 
pseudo-teletype to be logged out, regardless ot 
what state it is in. The pseudo- teletype is 
automatically logged out at the termination ot the 
program even it this is not explicitly requested. 



!ATT ( ) 

This function of" no arguments causes a pause 
in execution of the control program until the jot) 
on the pseudo- teletype is an a state where it can 
do nothing without recievmg more input,-. That is, 
it waits until the pseudo-teletype is done with 
its current computations. This tunction has a 
null value and causes ail output ot the 
pseudo-teletype, generated . while waiting to be 
lest. This tunction is necessary to guarantee 
that all output from past commands to the 
pseudo-teletype has been "generated. Without this 
facility we would be hard pressed to decide which 
output was associated with which command. 



SEND ( <striny> ) 

SEND first does a WAIT and then delivers the 
characters in the string to the pseudo- teletype as 
it requests input. The SEND function returns a 
.null value. 
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FOBCEn SEMD( <string> ) 

FORCED SEND forces the psuedo- teletype into 
the highest level ot the time-sharing system 
command language, interrupting any computation 
that may be executing.. .(A possible method of 
implementing this would be to send .a special 
escape character - to the input butt.Gr ol the 
pseudo-teletype ""which .-would be recognized by the 
tirae-sharing system - as a request lor .- this 
particular action.) Then the argument string is 
sent as with the SEND function. 



BECVCHAP( <number> ) 

KECVCHAR takes as argument an expression that 
evaluates to a positive integer, -N. Tt collects X 
. output characters trom the pseudo-teletype" 
resulting- Irom the last SEND or FORCED SEND 
function call, where X is less than or eguai to N. 
If there are less than » characters (nut at least 
one) then these characters are returned as the 
value of the function. It there are N or more 
characters of output then the first N characters 
are returned as the value. It there is no output 
then the function fails. 
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FECVIIKE ( ) 

The purpose ot this function is to gather 
output from the pseudo-teletype line by line. The 
function takes no arguments and returns as its 
value the next line from the output ot the 
pseu do- teletype. It there is no more out-put then 
the function fails. . 

ECHO { <nuniber> ) 

For conversational applications, it may fie 
desireable to occasionally allow the user to 
interact directly with the pseudo-teletype through 
his own console. A program to do this would 



a) accept a character {or characters) from the 

user 

h) SEND the characters to the pseudo-teletype 

c) gather the reply, it any, with RECVCHAH or 
BFCVLINE ... 

d) print the reply on. the user's console 

e) go to step a. 



However, input characters will appear twice in the 
output at the user's console - once tor his typing 
of the character, and once as part ot the output 
cf the pseudo- teletype. The function ECHO, when 
called with negative argument, turns ott the 
echoing of all characters input to the user's 
console. A subsequent call to ECHO with a 
ncn-negative argument will turn the echoing CacK 
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on again. This lunation has other uses in an 
interactive language; tor example, to accept 
secret passwords without having them printed. 

The appendix contains a program which represents an 
example of the use ot the above functions (in bedded in a 
SNOR0I3 language processor) operating on a hypothetical 
time-sharing system. The example demonstrates . a 
' straightforward application ot the tacility tor 
consolidating a lengthy command sequence into a single 
command. It also shows how. the conditional features can be 
used both to control and evaluate the execution ot the job 
and to do it with concise, parameterized programs. 

Ey providing a time-sharing system with a program to 
queue process control program tile names and a supervisor 
program to seguentailly execute process control, nobs from 
the queue, we can have a very reasonable background batch 
processing facility integrated into the system. These jobs 
would he able to communicate with the command languages ot 
the time-sharing system and could execute with a great deal 
of conditional control over themselves. It would he very 
convenient to prepare, edit and submit background jobs from 
a time-sharing console. 
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5.0 IMPLEMENTATION 



Implementation ot the above functions will vary 
depend inq on the characteristics ot the time-sharing system. 
The implementation at Berkeley required provision by the 
time-sharing , system ot tour privileged routines which when 
called by a suitably authorized program would: 



A) Simulate, the input . of a character at the 
keyboard ot another teletype. {i.e. put a 
character into the input butter ot that teletype.) 

B) Suppress the typing ot characters put into the 
cutout buffer of another teletype. 

C) Road characters out ot the output butter ot 
another teletype. 

D) Determine it another teletype is running a 
program which is dismissed waiting tor teletype 
input. 

Needless to say the physical existence of a teletype tor 
this got is not required. 

This method of implementation was influenced by the 
nature of the already existing time-sharing system, and is 
net completely satisfactory. When a process control gob is 
running under this implementation, the time-sharing system 
actually sees two separate jobs - the controlling program 
and the job being controlled. This means that two entry 
ports to the system are absorbed although the two jobs are 
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operated by only one user and seldom compute in parallel. 
Net only is this a waste of a valuable system resource, -Gut 
it also results in a difficult accounting problem. During 
process control, twice as much LOGIN time is charged than is 
actually spent by a user at a physical console. Another 
complaint is that the indirect approach ot using teletype 
buffers tor the communication ot commands Between the two 
jobs seems inefficient and, unclean. . 

In a more versatile operating system one would wish to 
cause the controlled job to execute as a subsidiary or 
parallel process of the controlling program. This 
introduces some problems however. It is important that the 
n controlled job execute exactly as it it were entered from a 
standard console. In particular, it must have ail the same 
capabilities (e.g. amount ot memory, number " ot devices 
attachable, number of files it can simultaneously open, 
etc). Also, its universe of discourse must be restricted to 
only its own created environment, and not that ot the 
controlling program. For example, it in the course ot its 
computation, the controlled job executes the operation 
"CLOSE ALL FILES", the controlling program should not be 
effected, ■ 

As for the command communication between the two jobs, 
a parameterized input/output structure is needed. We should 
te able to specify as one of the initial. parameters to a 
job, that its command input and output will taKe the form of 
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communication with a particular process control program. 
This will cause each call to a teletype input/output routine 
to execute an appropriate process communication routine 
instead of a teletype operation. Notice that it the 
operating system permits any operations which maice 
assumptions about the nature or command, input/output (e.g. 
"CLEA" TELETYPE OUTPUT BUFFER")' then these .routines must 
perform an equivalent operation when executed by a 
controlled job. 

'These" requirements tor a clean implementation o.t the 
conditional conversational command processing facilities are 
in fact general problems of current operating system design. 

6.U CONCLUSION 



In 1967 a special-purpose programming language devoted 
entirely to interactive process controlling called CCP 
(Conditional Command Processor) was implemented on the . SDS 
940 in the spirit of the above. The language had a profound 
impact, on the use of the time-sharing system by people who 
construct and maintain large programs. . The assembly and 
leading of these programs has been almost completely 
automated by the use of the language. The most notable 
example of this is the assembly and loading or the 
time-sharing system itself, which requires a CCP program six 
panes in length. The operations required are contusing 
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enough that the chance of their being performed correctly by 
humans is less than titty per cent: with CCP the entire 
process can be performed autouat icaily in a relatively short 
time with no human intervention required. 

New completed is the embedding o.t tnp functions listed 
above in an implementation ot SN030L4 at Berkeley. The much 
greater power in the SNOBOL language has enabled much more 
complex job control programs to be written, programs which 
can adjust their execution in a very flexible planner as they 
observe the course ot the job being controlled. For 
example, one programmer interested in a new interactive text 
editing command language has built an interface" with the 
standard editor on the system to allow experimentation with 
it. 

Sutler Lampson advised this research from the 
beginning, and with Larry Barnes -helped specify the 
communication functions and their, i mplementation on the SDS 
guo. 
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AS INPUT A LIST OF FILE NAMES 
NAMES OF SYMBOLIC ASSEMBLY 
ARE TO 3E SEPARATED BY COMMAS. 



NO 



♦THIS SNOBOL3 PROGRAM ACCEPTS 
♦WHICH ARE EXPECTED TO BE THE 
♦LANGUAGE PROGRAMS. THE NAMES 
* 

♦EACH FILE 'X' 'IS ASSEMBLED AND THE BINARY IS OUTPUT TO THE 
♦FILE 'BTNX'. AFTER ALL ASSEMBLIES HAVE BEEN DONE, THE FILES 
♦APE AIL LOADED AND THEN THE RESULTING CORE IMAGE IS DUMPED 
♦TO THE FILE CALLED' ' DUMP'.. IE THERE ARE ANY ERRORS DURING 
♦THE ASSEMBLY OF THE FILES, THE NAMES OF THE FILES 
♦AND. THE ASSOCIATED ERROR . MESS AGES ARE PRIMTbiD, BUT 
♦LOADING IS DONE, ' 

START LOGIN (SMITH, PASSWORD) 
♦SEND MESSAGE TO USER TO INPUT FILE NAMES 

OUTPUT = 'ENTER FILE NAMES! » ' 
♦READ IN THE FILE NAME LIST 

FILE LI ST = INPUT ', « 
♦THE CCKMA IS USED TO ALLOW SIMPLE 
♦INDIVIDUALLY REMOVE ALL THE NAMES 

FILECOPY = FILELIST 
♦THE CCPY OF THE LIST WILL BE USED DURING LOADING. 
ASSE.1PLCOP FILELIST ♦NAME* ',' = /F(LOAD) 
♦NOW .'NAM* 1 HAS AS VALUE THE NEXT FILE NAME TO ASSEMBLE 
SEND (' ASSEMBLE FILE: ' NAME ' TO FILE BIN* NAME) 
ASSEMBLOUT = RECVCHAR ( 1 OOOOOO) 
♦BY USING A LARGE NUMBER WE ARE SURE TO GET SLL THE 
♦MESSAGES GENERATED BY THE ASSEMBLER IN RESPONSE TO 
♦THE COMMAND SENT ABOVE. 



PATTERN MATCHING. 
FROM THE LIST. 



TO 



♦IE WE FOUND 
♦CI HER MS E « 
LOAD 



ASSEMBLOUT 
ASSEMBLOUT- 
ASSEMBLOUT ' 
ANY ERRORS 



'INVALID' ./S(ASSBMBLEHROE) 

' ER RO R ' / S ( A S S EM BL E R HO R ) 

' V /S (A5SEMBLERR0R) F { ASSEMBLOOP) 



♦NOW KE CAN 
ICADLCCF 

DUMP 
ASSEEBLEEROR 



♦AFT E R 
♦CTREE 

DONE 
* 



VIE WENT TO 
wii WENT BACK TO GET THE 
EQUALS (ERR03FLAG, 1) 
SEND ('LOADER SYSTEM') 
LOAD EACH FILE 
FILECOPY ♦NAME* 
SEND {'LOAD FILE 
SEND {'DUMP LOAD 
ERRORFLAG=1 
OUTPUT= 'FILE • NAM 
OUTPUT = ASSEMBLOUT 
PRINTING THE ERROR MESSAGES 
FILES IN CASE THEY ALSO HAV 



'ASSEMBLEKROR' , 
NEXT FILE NAME. 
/S (DONE) 



i t 
r 

BIN' 



ON 



/E(DUMP) 
NAME) /(LOAD LOOP) 
FILE: DUMP') /(DONE) 



I ' HAD ERRORS: ' 
/ (ASS EMB LOOP) 
UE HILL GO ASSEMBLE 
I ERRORS. 



T H E 



LOGOUT () 



/(END) 



